我的背景是5年的接案公司 + 1~2年的金融業，屬於前端成分偏重的全端工程師，比較常處理的是後台系統或是公司內部的系統(to B)。
這篇文章主要針對有用過 Angular 的朋友們，可能有用過但是不太了解為什麼，或是你遇到類似的問題，歡迎來聽我分享我的理解。有錯誤或是不夠清楚的地方也很歡迎一起討論。
技術環境說明
- UI樣式庫：NG-ZORRO
- Angular版本：文章會用Angular 17來寫，我習慣跟最新版本差2個版本（或以上）
- 如果想討論更舊版本也可以留言，因為我寫Angular 14比較久，可能會不小心寫到舊寫法，但原則上不影響展示內容
在實際工作中，我遇到的類型有全新專案、舊案維護、系統翻新、線下流程轉線上化，有的時候四種類型也會混在一起。
而比起全新的專案，更常遇到的其實是舊案維護或系統翻新。
以下四種不同類型的專案經驗：
這種專案通常會有設計師參與，可以協助釐清使用者想要的操作流程跟使用習慣（UX設）。我們也有機會從頭到尾參與會議，理解需求的脈絡、討論畫面需求跟API的差異，甚至有機會對資料庫設計提供意見，大大減少開發盲點。
程式碼也不會有世代疊代或不明汙染的問題，在開發時候比較順暢。
💡 提醒
新專案也有自己問題啦，可能版本一直確定不下來，但這跟需求管理比較有關，就不細述。
舊案維護代表你可能會遇到程式碼的斷層，這份程式碼可能是2手或3手處理的，你可能會找不到曾經的溝通管道跟對應文件。
情況：看著 price 跟 sPrice 這兩個欄位，完全搞不清楚今天使用者說要改的是哪一個，只能透過程式碼跟資料庫反向推測。
面對這類的歷史沉痾，基本上只能慢慢清理跟調整，沒聽說過有捷徑。有些人會直接註解或跳過去處理，也是一個辦法，我也可以理解非常時期有非常作法，但是大家都不想成為接手的下一個人😂
而且我們也其實阻止不了人員流動，所以只能在自己寫程式的時候，設身處地的盡量考慮可讀性、彈性跟複用性，讓大家的工作環境健康一點。至於如何達到可讀性、彈性跟複用性，會在後續分享我的經驗。
除了這些以外，我認為註記應該也要留下相對應的文字，才能透過公司系統、或是溝通窗口去找到對應的資訊，一方面也是保護工程師自己，當被質詢或是詢問的時候，才能明確說明這其實是某某時期的需求，準確的歸屬責任。
🔧 關於註記的建議
在程式碼裡留下部分註記，用來記錄說明需求：
- 需求日期、需求號碼、提出需求人等
- 用標籤或符號幫助尋找當時需求記錄
- 比較特殊的需求加上原因說明
- 一部分也是保護工程師自己
系統翻新這個類型，我遇過幾種不同的情況，情況如下：
以桌面應用和 TUI 翻 Web為 例：
雖然現在已經來到了 AI 的世代，但翻新成 Web 的需求體感還是滿多的。
這樣的專案，通常是公司裡面已經行之有年的專案，有許多細小的功能跟規則穿插在專案介面之間，但是這些功能都沒有留下文件記錄。
跟上一個舊系統維護其實很像，不過在執行這個專案的時候，通常會聽到兩句令人痛苦的話：
更棘手的是，要是對接系統的 API 規則佚失，或是跟 新舊系統系統介面有差異，這時候通常都不是改舊的那方，一定是正在翻新的系統扛下歷史共業。
另外被世界遺忘的業務規則，在上線實際串接時才發現問題，導致上線日期需要調整。
那些規則可能連使用者都不知道，因為使用者也有人員流動問題，最初盤點沒盤到的，很有機會在上線時才爆出來。
⚠️提醒
這是現實，無法避免，所以開始前會希望工作團隊一起有這個共識，如果你已經在坑裡，但團隊還沒有共識，讓你很痛苦的話，請記得這不是你一個人的問題～
接下這個類型案子之前，建議安排多留時間緩衝，或要求準備預上線環境。
這種案子很需要時間的彈性，還有高度模擬正式環境的預正式環境，急的話真的沒幫助，雙方都很容易虧錢跟傷害心理狀態。
這種專案通常也帶有審核需求，會分為前後臺介面。盤點的時候，會發現人工可以處理的問題是相當細膩的，所以要透過web來達到一樣的效果會有許多的UX功能需要帶入，光是檢查註冊表單有沒有寫錯，可能就要切出許多驗證方法跟好幾個元件跟服務。
主要的挑戰會在於讓使用者操作流暢，還有符合人工驗證的細膩，像是A的話才可以填B、C，C大於α的話，必須再提交D文件才可以過審，人工的話，熟練的人可能看一眼就通過，但變成程式邏輯的話就會變得很多行。
🦾挑戰
- 流暢的 UIUX 實踐
- 複雜的驗證邏輯
後臺通常會跟一到多個前臺搭配，處理資料的檢視、變更、刪除、新增或審核，也可能是監控多臺機器，或顯示特定資料源的資料。
而他通常不是顯示一個表格或是圖形就結束，因為拿到的資料，跟畫面上需求不見得一致，跟使用者操作習慣也不一定一樣，常常需要對資料做一部分的處理跟過濾，才能符合需求或是畫面上需要調整設計。
除了資料處理，後臺大部分都會有權限需求，不論是透過 SSO 登入或自己有登入頁面，裡面的資料都是被認證過的人才可以查看跟異動。所以不論這個後臺多小，在畫面跟程式框架上都必須考慮權限設計。
我個人經驗中，後臺提供的規格，並沒有設計師提供的設計稿😅， 如果要有設計師，都是在有到客戶端的專案才會排預算。
或是設計師有參與，但是只是提供一個樣式主題，並不會協助釐清 UX 的流程，因為這個專案給他們的資源有限，所以他們也不會參與到太細節的部分。有足夠資源讓設計師從頭參與到尾的機會實在偏少。通常在第一次提供給使用者使用之後，他們才會反應跟原來使用流程不一樣，或跟預期不同。
同個專案會有多個地方有相同功能，這時候為了避免改了A沒改到B的悲劇，每次需求調整都要重新盤點哪裡有這個功能，但是人工盤點還是難以100%達成。
我的解決方式是透過元件化跟 Monorepo 來處理，Monorepo 也可以一併處理設計主題統一性的問題。
在公司實務上，同一間公司需要的元件跟常用設計可能很一致，但不可能所有專案都塞在一起引用彼此。
這時候可以透過 Verdaccio 在私人主機安裝，也就是私人的 npm，這樣就能管理公司內部的元件庫。
根據以上提到的經驗，我預計分享以下內容，如果剛好有你有興趣的內容，歡迎看看：
iThome鐵人賽
看影片追技術